\chapter{Theoretical Foundation}
\section{Introduction}
\vspace{-4mm}
Following the article \textit{IT Doesn't Matter}, published in the \textit{Harvard Business Review}, ``\textit{the evolution of information technology in business follows a pattern strikingly similar to that of earlier technologies like railroads and electric power. For a brief period, as they are being built into the infrastructure of commerce, these ``infrastructural technologies'', open opportunities for forward-looking companies to gain strong competitive advantages. But as their availability increases and their cost decreases - as they become ubiquitous - they become commodity inputs. From a strategic standpoint, they become invisible; they no longer matter`` \parencite{Carr2003}}. After almost one decade, the previously stated hypothesis can't be denied, enterprises' core processes highly rely on IT and there starts the dilemma, as today's enterprise software development often suffers from a lack of agility and under inefficiency \parencite[p. 25]{Krafzig2007}.

\noindent
According to \textcite[p. 27]{Krafzig2007}, the requirements for an enterprise software architecture are \textit{simplicity}, \textit{flexibility and maintainability}, \textit{reusability}, \textit{decoupling business-logic and technology}. In the discussion about enterprise software must be considered, that a majority of the occurring problems are not of technical nature, but of organizational nature. Due to the inhomogeneity between technical and business related concepts as well as due to the different languages, several unsuccessful attempts have been observed to reduce  Business and IT concepts to ``a common denominator'', since the idea of SOA has been came up \parencite[p. 32]{Krafzig2007}. Although SOA supports alignment between Business and IT, the implementation of a SOA is challenging, as architects permanently need to consolidate due to conflicting business requirements and progress in infrastructure capabilities. 

\noindent
In the upcoming sections, the necessary constructs for this thesis are explained. Despite of not giving a general introduction into SOA in the upcoming sections, worth mentioning is, that best practice approaches used for this thesis mainly originate from  \textcite{Erl2009}, \textcite{Erl2008}, \textcite{Erl2008b}, \textcite{Starke2007} and \textcite{Krafzig2007}.

\section{Definitions around SOA}
\vspace{-4mm}
To introduce the concepts used in this thesis, some cites within SOA are stated below.

\par
\begingroup
\leftskip=0.5cm
\rightskip=0.7cm
\noindent
``\textit{SOA establishes an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing}'' \newline \parencite[p. 38]{Erl2008}.
\par
\endgroup
\noindent

\par
\begingroup
\leftskip=0.5cm
\rightskip=0.7cm
\noindent
``\textit{Services are independent building blocks that collectively represent an application}'' \parencite[p. 3]{Perepletchikov2005}.
\par
\endgroup
\noindent

\par
\begingroup
\leftskip=0.5cm
\rightskip=0.7cm
\noindent
``\textit{Service granularity generally refers to the size and functionality of a service}'' \parencite[p. 378]{Karthikeyan2012}.
\par
\endgroup
\noindent

\par
\begingroup
\leftskip=0.5cm
\rightskip=0.7cm
\noindent
``\textit{Coupling is defined as a measure of the extent to which interdependencies exist between software modules. Cohesion is defined as the extent to which elements of a module contribute to one and only one task}'' \newline\parencite[p. 3]{Perepletchikov2005}.
\par
\endgroup
\noindent

\par
\begingroup
\leftskip=0.5cm
\rightskip=0.7cm
\noindent
``\textit{Like low coupling, high cohesion is a service-oriented design and development principle to keep in mind during all stages in the methodology. High cohesion increases the clarity and ease of comprehension of the design; simplifies maintenance and future enhancements; achieves service granularity at a fairly reasonable level; and often supports low coupling. Highly related functionality supports increased reuse potential as a highly cohesive service module can be used for very specific purposes}'' \parencite[p. 5]{Papazoglou2006}.
\par
\endgroup
\noindent

\section{Service Dimensions}
\vspace{-4mm}
Inspired by \textcite{Keen1991}, \textcite{Weill1998} applied the origin concept of \textit{reach} and \textit{range} and related it to what type of functionalities IT infrastructure services have, and for whom. \textcite[p. 262]{Weill1998} defined reach  as the locations and people the infrastructure is capable of connecting, whereas the range is the extent of provided functionality.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=5, trim=1.97cm 5.86cm 1.97cm 3.87cm, keepaspectratio=true, scale=.6, clip=true]{graphics/approach}
			\caption[Overview Service Dimension]{Overview Service Dimension (adapted from \cite{Reldin2007)}}
			\label{Overview Service Dimension}
		\end{center}
\end{figure}

\noindent
\textcite[p. 57]{Reldin2007}, elaborated the concept once more, and added the \textit{realm} dimension, which makes the object transparent in the model to better promote reuse of any kinds (objects), as seen in figure \ref{Overview Service Dimension}. By means of this concept, services within a SOA can described with clear business relations.

\section{Service Granularity}
\vspace{-4mm}
According to \textcite[p. 118]{Erl2008}, service granularity refers to the functional scope of the service and is split up as follows:

\begin{itemize}
  \item Capability granularity refers to the scope of a specific capability.  
  \item Data granularity refers to the amount of data exchanged by a service.
  \item Constraint granularity refers to the level of detail to which validation logic is coupled on a particular data parameter or capability within the service contract.
\end{itemize}

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=6, trim=5.02cm 6.65cm 4.22cm 4.59cm, keepaspectratio=true, scale=0.6, clip=true]{graphics/approach}
			\caption[Overview service granularity]{Overview service granularity (adapted from \cite{Reldin2007})}
			\label{Overview service granularity}
		\end{center}
\end{figure}

\noindent
Going further, bringing the definitions of service granularity from \textauthor{Erl2008} in relation with business terms, related capabilities and associated data entities defined in a service contract\footnote{Note, for simplicity reasons services' constraints are not taking into closer consideration.} can be related to a reach, range and realm, as seen in figure \ref{Overview service granularity}.

\noindent
By means of the business terms, alignment between business and IT can be increased and the dialogue goes away from purely technical, abstract concepts. To quantify  the granularity of a service, the volume of a  ``building block'' is used. Thus, fine grained services cover a small set of reach, range and realm, whereas coarse-grained services have a bigger volume, hence cover a broader range, reach and realm.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=7, trim=1.96cm 6.67cm 2.61cm 4.59cm, keepaspectratio=true, scale=0.6, clip=true]{graphics/approach}
			\caption[Example service granularity]{Example service granularity}
			\label{Example service granularity}
		\end{center}
\end{figure}

\noindent
Figure \ref{Example service granularity} reflects two service inventories handling the same scope (the same reach, range and realm). On the left hand side, a coarser-grained service is shown, compared to the right, where five finer-grained services are in place, but covering the same reach, range and realm.

\section{Internal Structural Software Attributes}
\vspace{-4mm}
The concept of functional independence, which is addressed by internal structural software attributes, is an outgrowth of \textit{separation of concerns}, \textit{modularity}, \textit{concepts of abstraction} and \textit{information hiding} \parencite{Wirth1971, Parnas1972, Stevens1979}. ``Functional independence is achieved by developing modules with ``single-minded'' function and an ``aversion'' to excessive interaction with other modules'' \parencite[p. 227]{Pressman2010}. ``Single mindness'' and ``aversion to excessive interaction'' can be bridged to structural software attributes, whereas ``cohesion'' relates to the former and ``coupling'' to the later. Hence, independence can be assessed by means of these two quality criteria.
\newline
\noindent
Relating this with SOA - aiming to provide business logic by means of independent building blocks, coupling and cohesion serves as a quality criteria for services, which have a certain degree of granularity. Therefore, service granularity cannot stand on its own and requires coupling and cohesion to come to meaningful conclusions. This gets obvious when looking into the former example, shown in figure \ref{Example service granularity}. Only by evaluating the quality criteria related to ``single mindness'' and ``the amount of coupling'' between the building blocks, qualitative conclusions can be drawn, whether the chosen degree of granularity of the services in the inventory. So answering questions like ``Which inventory does more comply with the overall guidelines of a SOA project?'' or ``Which inventory does better support reuse?'' could be supported and underpinned by having absolute terms of previously discussed indicators. 

\subsubsection{Cohesion}
\vspace{-4mm}
In the context of SOA, \textcite[p. 83]{Daghaghzadeh2011} define cohesion as ``the degree of functional relevance of activities which are performed by a service to realize a business process''. Relating this with the previously defined example (figure \ref{Example service granularity}), the cohesion criteria indicates to which degree a given building block concentrates on just one thing. The former defined OO cohesion types \parencite{Lethbrdige2001}, such as \textit{functional}, \textit{layer}, \textit{communicational} play also an essential role in SOA, as functional and layer related cohesion are tackled by recommended service layers and models in the context of SOA best-practices. Moreover, \textcite{Perepletchikov2007} define the following cohesion types in the context of SOA: \textit{coincidental}, \textit{logical}, \textit{communicational}, \textit{external}, \textit{sequential}, \textit{implementation}, \textit{conceptual}. With respect of this thesis sequential (degree of output of one operation serving as input of another operation), implementation (degree of communality of underlying service components), communicational (degree of same data abtraction) and conceptual (degree of semantical information origin from domain model) are the most essential.

\subsubsection{Coupling}
\vspace{-4mm}
Considering SOA, \textcite[p. 433]{Perepletchikov2005} defines coupling as ``a measure of the extent to which interdependencies exist between implementation of services in software''. By measuring coupling with respect to the prior defined example (figure \ref{Example service granularity}), a qualitative indication of the degree to which the services are connected to other services is retrieved. Obviously, some coupling must be given in the right-handed inventory, as both inventories inherently encapsulate the same range, reach and realm, and thus its building block collectively possess the same amount of granularity, as the service shown on the left hand side. \textcite{Papazoglou2002} define three types of coupling, such as \textit{representational} (independence on representational and computational specifics), \textit{identity} (decoupling of provider and consumer) and \textit{communicational} (reduction of communication only to the most necessary details) coupling.

\section{Service Layers}
\vspace{-4mm}
SOA aims to abstract logic in software systems to produce reusable and composeable building blocks. Best-practice approaches foresee service layers, in order a certain degree of abstraction can be guaranteed.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=23, trim=4.55cm 6.24cm 5.41cm 4.68cm, keepaspectratio=true, scale=0.7	, clip=true]{graphics/approach}
			\caption[Service Layers)]{Overview service layers (adapted from \cite{Erl2008b})}
			\label{Service Layers}
		\end{center}
\end{figure}

\noindent
Reflecting figure \ref{Service Layers}, the three service layers in a SOA are \textit{orchestration} service layer, \textit{business} service layer and \textit{application} service layer. From bottom to top, services exposed in the application service abstract application logic of existing applications (could be legacy applications as well), are \textit{solution-agnostic}, generic and reusable. The business service layer abstracts the application layer and provides the enterprise-wide business logic for processes. Typically the services residing in this layer act as a controller accessing a collection of application layer related services. The orchestration layer composes business and application services. Often, in this layer are orchestration engines in place, which execute executable business process models containing the business process flow control logic. How many of these layers exist in a SOA initiative highly depends on the desired SOA target model\footnote{With respect of this thesis, behind target model is the layer concept within the SOA related.}. By means of having solely the application layer in place, reuse can be promoted. In case a more distributed environment is in place, a business service layer has its benefits but brings substantial investments and complexity. Having on top an orchestration layer promotes centralization and also agility if services below are designed as business-agnostic and solution-agnostic reusable services.

\section{Service Models}
\vspace{-4mm}
Every service layer has its service models in place. Worth mentioning thereby is, that there is in practice no common language of these service models, often also named as ``service types''. However, for this thesis the service models \textcite{Erl2008b} (table \ref{Service Models}) have been used. Because  every kind of service model follows a specific task related to its abstraction level, the service granularity differs depending on the service model, the service belongs to.

\begin{table}[ht]
		\begin{center}
	    	\includegraphics[page=12, trim=0cm 11.52cm 8.65cm 0cm, keepaspectratio=true, scale=0.7	, clip=true]{graphics/approach}
			\caption[Service Models)]{Overview service models (adapted from \cite{Erl2008b}); Note, the list is not holistic, because only concrete service models (no generic models) are listed, in order affiliation to service layers are getting more obvious.}
			\label{Service Models}
		\end{center}
\end{table}

\section{Metrics}
\vspace{-4mm}
Software metrics allow a measurement of quality characteristics. With respect of conformity of the metrics, the evaluation criteria from \textcite{Weyuker1998} and \textcite{Briand1996} have been mainly applied by the authors of metrics, listed in the upcoming section.	 